home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9608 / 000011_owner-urn-ietf _Thu Aug 15 10:24:45 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA01913 for urn-ietf-out; Thu, 15 Aug 1996 10:24:45 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA01908 for <urn-ietf@services.bunyip.com>; Thu, 15 Aug 1996 10:24:33 -0400
  3. Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA11443  (mail destined for urn-ietf@services.bunyip.com); Thu, 15 Aug 96 10:24:30 -0400
  5. Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id IAA00942; Thu, 15 Aug 1996 08:24:20 -0600 (MDT)
  6. Message-Id: <2.2.32.19960815142934.006a97b4@acl.lanl.gov>
  7. X-Sender: rdaniel@acl.lanl.gov
  8. X-Mailer: Windows Eudora Pro Version 2.2 (32)
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset="us-ascii"
  11. Date: Thu, 15 Aug 1996 08:29:34 -0600
  12. To: Lewis Girod <girod@LCS.MIT.EDU>, jon@net.lut.ac.uk
  13. From: Ron Daniel <rdaniel@acl.lanl.gov>
  14. Subject: Re: [URN] nasty rewriting rules
  15. Cc: urn-ietf@bunyip.com
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: Ron Daniel <rdaniel@acl.lanl.gov>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. Thus spoke Lewis Girod (at least at 03:54 PM 8/13/96 -0400):
  22.  
  23. >   On Tue, 13 Aug 1996 15:02:24 +0100 (BST) Jon Knight wrote
  24. >
  25. >   Regexp interpreters are already available in source code format that you 
  26. >   can just plug and play on many current platforms and which will ease 
  27. >   porting to new architectures.
  28. >
  29. >Fair enough, although it is important to have agreement as to what
  30. >flavor of regexps are being used.  The original plan was to just
  31. >execute sed, which solves both issues on UNIX platforms, but requires
  32. >a little more work otherwise.
  33.  
  34. Um, no, that was not the plan. The plan was to use regexp libraries, the
  35. syntax of the regexps was "sed-style" rather than "perl-style" because
  36. we believe that sed-style is actually the version most regexp libraries
  37. support.
  38.  
  39. >The fact remains that unless such
  40. >syntax-checking regexps are actually implemented at the top level,
  41. >there is no guarantee that a namespace will retain a set structure.
  42.  
  43. We have not had any plans to use regexps that also validate the form
  44. of the URN and report errors. 
  45.  
  46. >There is some suggestion in the framework document that there be a set
  47. >of requirements of new name schemes
  48.  
  49. Well, I thought that those requirements were going to be things like
  50. no reassigning of naming authorities, making sure that any naming
  51. authorities in a naming scheme require any sub-naming authorities to follow
  52. rules at lesat as restrictive as the ones they operate under, ...
  53.  
  54. So, these really are requirements on naming schemes and the operations
  55. behing them. Such requiremnts can't be tested by validating the syntax of
  56. a URN - useful thought that might be.
  57.  
  58.  
  59. >   Of course those of us that do 
  60. >   want regexp are still free to have a "NAPTRclassic" (:-) ) namespace 
  61. >   hived off using SRV records that does do regexp replacement, so maybe we 
  62. >   can all have our cake and eat it?
  63.  
  64. No, the syntax and capabilitites of the rewrite rules are a property of
  65. the NAPTR record, not of individual namespaces. The question before the
  66. group is if NAPTR rewrite rules should be regexps or something else.
  67. Lewis' proposal is, so far at least, the only alternative that has been
  68. advanced. I don't think we can have both, we have to decide.
  69.  
  70.  
  71. >I am the first to say that the terse syntax is wretched, but it was
  72. >really easy to implement and it is terse enough to easily fit into a
  73. >DNS response.
  74.  
  75. Being short enough to fit into a DNS response is quite important for
  76. efficiency considerations. Exceeding 512 bytes in a response shifts us
  77. from UDP to TCP. Also, we want to have plenty f room so that we can include
  78. SRV and A records as additional information to reduce the number of
  79. queries to DNS.
  80.  
  81. >Humans are supposed to use the simple user-friendly
  82. >syntax that compiles into the terse form.  With decent management
  83. >software the underlying terse form should be transparent to the
  84. >administrator -- in fact, if we can assume that everyone is using a
  85. >compiler it might be a good idea to make the terse form even more
  86. >compact.
  87.  
  88. Those are pretty strong assumptions Lewis. Furthermore, this software
  89. also has to decompile the terse form into the friendly form so that
  90. people can debug existing records. This sort of friendly software
  91. rarely gets written and maintained.
  92.  
  93.  
  94. Regards,
  95.  
  96. Ron Daniel Jr.                       email: rdaniel@lanl.gov
  97. Advanced Computing Lab               voice: +1 505 665 0597
  98. MS B287                                fax: +1 505 665 4939
  99. Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
  100. Los Alamos, NM, USA  87545       tautology:"Conformity is very popular"
  101.